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(54) System and method for transporting IN/AIN signaling over an internet protocol (IP) network 



(57) A system and method for transporting IN/AIN 
signaling (e.g., SS7 signaling) over an IP-based net- 
work using Stream Control Transmission Protocol 
(SCTP), wherein a peer-to-peer protocol adaptation 
(PPA) structure is provided at a signaling node. The 
PPA structure includes an interworking functionality 
between an MTP3 layer and the SCTP messaging, and 
operates to provide a symmetrical MTP2 adaptation 
interface therebetween. The PPA interface functionality 
facilitates the implementation of network management 
capabilities included in the MTP3 layer such that the 



advantageous features of SS7 signaling are retained in 
the SCTP transport. The MTP2 adaptation interface 
functionality is processed locally with respect to the sig- 
naling node, rather than backhauling the associated sig- 
naling to an external node via an IP connection. The 
PPA structure may be provided at any signaling node 
operable to establish a virtual link across an IP connec- 
tion such as, for example, a signaling gateway, an IP- 
compliant SCP or STP, et cetera. 
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Description 

PRIORITY STATEMENT UNDER 35 U.S.C. §1 1 9(e) & 
37 C.F.R. §1.78 

[0001] This nonprovisional application claims prior- 
ity based upon the following prior U.S. provisional patent 
application entitled: "Method And Apparatus For Trans- 
port Of AIN Messages Over IP Networks," Ser. No. 
60/155,041 (Prior Attorney Docket Number: 1098-00), 
filed September 21, 1999, in the name(s) of: Ram 
Dantu. 

BACKGROUND OF THE INVENTION 
Technical Field of the Invention 

[0002] The present invention relates to networks for 
effectuating telecommunications signaling. More partic- 
ularly, and not by way of any limitation, the present 
invention relates to a system and method for transport- 
ing IN/AIN signaling messages over a packet-switched 
network (PSN) such as an Internet Protocol (IP)-based 
network using an IP transport protocol. 

Description of Related Ar t 

[0003] Out-of-band signaling establishes a sepa- 
rate channel for the exchange of signaling information 
between call component nodes in order to set up, main- 
tain and service a call in a telephony network. Such 
channels, called signaling links, are used to carry all the 
necessary signaling messages between the nodes. 
Thus, for example, when a call is placed, the dialed dig- 
its, trunk selected, and other pertinent information are 
sent between network switches using their signaling 
links, rather than the trunks which will ultimately carry 
the bearer traffic, i.e., conversation. 
[0004] Out-of-band signaling has several advan- 
tages that make it more desirable than traditional in- 
band signaling. First, it allows for the transport of more 
data at higher speeds than multi-frequency (MF) out- 
pulsing used in the telephony networks without it. Also, 
because of separate trunks and links, signaling can be 
done at any time in the entire duration of the call, not 
just at the beginning. Furthermore, out-of-band signal- 
ing enables signaling to network elements to which 
there is no direct trunk connection. 
[0005] Signaling System No. 7 (SS7) provides a 
packet-based signaling architecture that has become 
the out-of-band signaling scheme of choice between 
telephony networks and between network elements 
worldwide. Three essential components are defined in a 
signaling network based on SS7 architecture. Signal 
Switching Points (SSPs) are basically telephone 
switches equipped with SS7-capable software that ter- 
minate signaling links. SSPs generally originate, termi- 
nate, or switch calls. Signal Transfer Points (STPs) are 



the packet switches of the SS7 network. In addition to 
certain specialized functions, they receive and route 
incoming signaling messages towards their proper des- 
tination. Finally, Service Control Points (SCPs) are data- 
bases that provide information necessary for advanced 
call-processing and Service Logic execution. 
[0006] As is well known, SS7 signaling architecture, 
effectuated as a multi-layered protocol, is standardized 
under the American National Standards Institute (ANSI) 
and the International Telecommunications Union (ITU) 
to operate as the common "glue" that binds the ubiqui- 
tous autonomous networks together so as to provide a 
"one network" feel that telephone subscribers have 
come to expect. Furthermore, SS7 signaling has made 
it possible to provision a host of advanced services (or, 
Value-added Services) based on Intelligent Network 
(IN) / Advanced Intelligent Network (AIN) architectures 
in both wireless and wireline telecommunications net- 
works. 

[0007] Due to the phenomenal growth in popularity 
of the Internet, there has been a tremendous interest in 
using packet-switched network (PSN) infrastructures 
(e.g., those based on Internet Protocol (IP) addressing) 
as a replacement for, or as an adjunct to, the existing 
circuit-switched network (CSN) infrastructures used in 
today's telephony. From the network operators' per- 
spective, the inherent traffic aggregation in packet- 
switched infrastructures allows for a reduction in the 
cost of transmission and the infrastructure cost per end- 
user. Ultimately, such cost reductions enable the net- 
work operators to pass on the concomitant cost savings 
to the end-users. 

[0008] Additional factors that are driving the current 
trend in transporting the bearer traffic on integrated 
and/or hybrid networks are: improvements in the quality 
of Voice-over-IP (VoIP) telephony; the Internet phenom- 
enon; emergence of standards; cost-effective price- 
points for advanced services via media-rich call man- 
agement, et cetera. Some of the emerging standards in 
this area are the well known H.323 protocol, developed 
by the ITU, Session Initiation Protocol (SIP) or Internet 
Protocol Device Control (IPDC) by the Internet Engi- 
neering Task Force (IETF), or Simple/Media Gateway 
Control Protocol (SGCP or MGCP). Using these IP- 
based standards, devices such as personal computers 
can inter-operate seamlessly in a vast inter-network, 
sharing a mixture of audio, video, and data across all 
forms of packet-based networks which may interface 
with circuit-switched network portions. 
[0009] To seamlessly integrate carrier-grade serv- 
ice architectures within IP-based networks, it has there- 
fore become necessary to provide the capability to 
transport out-of-band signaling information (such as the 
SS7 signaling) on IP connections also. The state-of-the- 
art technology for facilitating such SS7-over-IP trans- 
port includes utilizing a connection-oriented IP transport 
protocol, called Stream Control Transmission Protocol 
(SCTP), for transmitting SS7 signaling messages 
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across the network elements. Clearly, it is highly desira- 
ble that such transport not disrupt or degrade the capa- 
bilities of the signaling network, as they are essential in 
effectuating various advanced services. In particular, it 
is necessary for applications involving the higher layers 5 
of the SS7 protocol (e.g., Transaction Capabilities Appli- 
cation PartorTCAP, Signaling Connection Control Part 
or SCCP, or various User Parts such as ISDN User Part 
or ISUP, Telephony User Part or TUP, and Data User 
Part or DUP) to operate without any degradation when w 
the SS7 messages are transported by means of SCTP 
That is, message dialogs (e.g., call setup, etc.) in these 
applications should remain unaffected even when the 
messages are sent over IP (transport-independency). 
Accordingly, SS7-over-IP mechanisms must satisfy the 75 
following requirements which are traditionally provi- 
sioned in pure SS7 networks: 

High reliability; 

High availability; 20 
Short error handling time; and 
Extremely low error rates. 

[0010] In general, the functionality of the lower Mes- 
sage Transfer Part (MTP) portion of the SS7 protocol 25 
(Level-2 MTP (MTP2) and Level-3 MTP (MTP3) layers, 
in particular) is responsible for link control and manage- 
ment, network reliability, error handling, etc. Conse- 
quently, the MTP functionality of the messages must be 
preserved as much as possible as they are transported 30 
over SCTP. 

[0011] Several shortcomings and deficiencies exist 
in the state-of-the-art architectures for effectuating SS7- 
over-IP. In order to accommodate the MTP functionality, 
the existing schemes involve what is known as "back- 35 
hauling" of the signaling messages over an IP network 
to an IP signaling gateway (SG) for processing. Not only 
does this procedure introduce asymmetrical behavior at 
the two ends of the SS7-IP interface, but additional 
complexity related to Operations and Administration of 40 
the backhauling path is also created accordingly. Fur- 
ther, it should be readily appreciated that where multiple 
SGs are provided and each is operable to receive back- 
hauled signal traffic via its own path, such complexity 
can quickly become unmanageable. 45 
[0012] Moreover, because the paths used for back- 
hauling the signaling traffic necessarily involve IP con- 
nections, such paths are beset with the inherent 
unreliability of IP connectivity. 

50 

SUMMARY OF THE INVENTION 

[0013] Accordingly, the present invention is directed 
to an innovative solution for transporting IN/AIN signal- 
ing (e.g., SS7 signaling) over an IP-based network 55 
using SCTP, wherein a peer-to-peer protocol adaptation 
(PPA) structure is provided at a signaling node. The 
PPA structure includes an interworking functionality 



between the MTP3 layer and the SCTP messaging, and 
operates to provide a symmetrical MTP2-user adapta- 
tion interface (MTP2-user peer-to-peer adaptation, or 
M2PA, interface) therebetween. The PPA functionality 
facilitates the implementation of network management 
capabilities included in the MTP3 layer such that the 
advantageous features of SS7 signaling are retained 
while transported over the IP network using the SCTP 
protocol. The M2PA interface functionality is processed 
locally with respect to the signaling node, rather than 
backhauling the associated signaling to an external 
node via an IP connection. The PPA structure may be 
provided at any signaling node operable to establish a 
virtual link across an IP connection such as, for exam- 
ple, a signaling gateway an IP-compliant SCP or STP, 
et cetera. 

[0014] In one aspect, the present invention is 
directed to a telecommunications network element 
operable in the transport of signaling messages over an 
IP-based network. The network element comprises a 
first structure operable to effectuate signaling communi- 
cation over a signaling network using a signaling proto- 
col (e.g., common channel signaling such as SS7 
signaling, or an access signaling protocol such as the 
Q.931 protocol). A second structure in the network ele- 
ment is operable to transport the signaling communica- 
tion across a packet-switched network using an IP- 
based transport protocol such as the SCTP protocol. A 
PPA structure is included in the network element and is 
operably associated with the first and second struc- 
tures. The PPA structure operates to convert the signal- 
ing communication between the signaling protocol 
messages and the IP-based SCTP messages. In 
accordance with the teachings of the present invention, 
the PPA structure includes a functionality to facilitate the 
first structure to locally process the signaling protocol's 
signaling messages without backhauling them to an 
external node. 

[0015] In another aspect, the present invention is 
directed to a telecommunications network which com- 
prises a first network portion operable to transport sign- 
aling messages using SS7 protocol and a second 
network portion based on IP. The second network por- 
tion is provided to be operable to transport the signaling 
messages using SCTP. A signaling gateway is disposed 
between the first and second network portions, the sig- 
naling gateway including a PPA structure operable to 
interwork between the SS7 protocol and SCTP messag- 
ing, wherein the PPA structure provides a symmetrical 
MTP2-like interface between MTP3 layer of the SS7 
protocol and the SCTP protocol. The PPA structure 
includes the functionality to locally process functions 
associated with the MTP2-like layer at a local node. 
[0016] In a yet further aspect, the present invention 
is directed to a method of transporting SS7 signaling 
information over an IP-based network. The method 
commences by establishing a virtual link across an IP 
connection between two nodes disposed in the network. 
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The virtual link is provided to be operable to propagate 
messages using SCTR Thereafter, the virtual link's 
integrity is verified by one or both of the two nodes 
which may be disposed in a client/server relationship. At 
each of the two nodes, an interworking process is effec- 
tuated between MTP3 functionality and the SCTP proto- 
col by a PPA structure provided thereat. The PPA further 
operates to convert SS7 signal bearer traffic into a 
stream of SCTP messages. Subsequently, the virtual 
link is loaded with the stream of SCTP messages for 
propagation between the two nodes overthe virtual link. 
[0017] In a related aspect, the present invention 
provides a computer-accessible medium that is opera- 
ble with a signaling node disposed in an IP-based net- 
work such as the network set forth hereinabove. The 
computer-accessible medium carries a sequence of 
instructions or operations (and/or data) which, when 
executed by a processing entity associated with the sig- 
naling node, causes the signaling node to perform a plu- 
rality of steps for transporting SS7 messages over IP 
connections as described above. 
[0018] In yet another aspect, the present invention 
is directed to a link changeover method in an IP-based 
telecommunications network for transporting SS7 sign- 
aling information. The network includes a local node 
and a remote node, wherein each of the nodes includes 
an MTP3 structure, an M2PA structure, and an SCTP 
structure. Initially, an operational link is established 
between the local and remote nodes by creating one or 
more SCTP associations therebetween. Upon detect- 
ing, by either or both of the nodes, that a select condi- 
tion related to the association (e.g., link failure, packet 
loss, Quality of Service (QoS) degradation, etc.) has 
occurred, the nodes engage in a procedure for 
exchanging message sequence number information on 
an alternative link established therebetween. Thereaf- 
ter, messages are retransmitted over the alternative 
link, the messages starting at a predetermined 
sequence number based on the message sequence 
number information exchanged between the nodes. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0019] A more complete understanding of the 
present invention may be had by reference to the follow- 
ing Detailed Description when taken in conjunction with 
the accompanying drawings wherein: 



FIGS. 3A and 3B 



FIG. 1 



FIG. 2 



depicts a network portion wherein 
SS7 messages are transported over 
an IP connection provided in a cur- 
rent architecture; 

depicts a telecommunications net- 
work having an SS7 signaling net- 
work portion and an IP-based 
network portion, wherein the teach- 
ings of the present invention are 
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15 



20 



55 



FIG. 4A 



FIG. 4B 



25 FIGS. 5A and 5B 



30 FIG. 5C 



35 FIGS. 6A and 6B 



40 FIG. 7 



45 FIG. 8 



so FIG. 9 



FIG. 10 



advantageously practiced; 

depict two exemplary embodiments 
of a network portion wherein SS7 
messages are transported over an 
IP connection by utilizing a Level 2 
MTP-User peer-to-peer adaptation 
(M2PA) layer structure provided in 
accordance with the teachings of the 
present invention; 

depicts an exemplary arrangement 
of the various network elements 
wherein multiple signaling scenarios 
may be implemented in accordance 
with the teachings of the present 
invention; 

depicts an exemplary link connec- 
tion arrangement between two 
nodes wherein multiple alternative 
links may be advantageously imple- 
mented; 

depict an example of the formation 
of an SCTP association between 
two nodes disposed in a client- 
server relationship; 

is a flow chart of the steps involved 
in an exemplary method for trans- 
porting SS7 messages over an IP 
connection; 

depict various message flows for 
effectuating the M2PA layer struc- 
ture in accordance with the teach- 
ings of the present invention; 

depicts a message flow diagram for 
effectuating link initialization in 
accordance with the teachings of the 
present invention; 

depicts a message flow diagram for 
effectuating link confirmation in 
accordance with the teachings of the 
present invention; 

depicts a message flow diagram for 
effectuating message transmission 
and reception in accordance with 
the teachings of the present inven- 
tion; 

depicts a message flow diagram for 
effectuating link status indication in 
accordance with the teachings of the 
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present invention; 

FIG. 1 1 depicts a message flow diagram for 

indicating processor outage in 
accordance with the teachings of the 5 
present invention; 

FIG. 12 depicts a message flow diagram for 

effectuating congestion notification 
in accordance with the teachings of 10 
the present invention; 

FIG. 13 depicts a message flow diagram for 

effectuating link deactivation in 
accordance with the teachings of the 15 
present invention; and 

FIG. 14 depicts a message flow diagram for 

effectuating link changeover in 
accordance with the teachings of the 20 
present invention. 

DETAILED DESCRIPTION OF THE DRAWINGS 

[0020] In the drawings, like or similar elements are 25 
designated with identical reference numerals through- 
out the several views thereof, and the various elements 
depicted are not necessarily drawn to scale. Referring 
now to FIG. 1 , depicted therein is an exemplary network 
portion 100 wherein SS7 messages are transported 30 
over an IP connection provided in a current architecture. 
A signaling endpoint (SEP) 1 02 is coupled to a signaling 
gateway (SG) 104 via an SS7 path 108 which may 
involve one or more Signal Transfer Points (STPs) and 
multiple link sets in some implementations. A media 35 
gateway controller (MGC) 106 disposed in an IP net- 
work (not shown) is coupled to the SG 104 via an IP 
connection 1 1 0 which provides for the transport of sign- 
aling messages using an IP transport protocol such as 
the SCTP protocol. The IP connection path 110 may 40 
also involve multiple IP links as may be required. 
[0021] SEP 102 is operable as a node in an SS7 
network (not shown) that originates or terminates sign- 
aling messages, such as a central office (CO) switch. 
The SG 104 is operable as a signaling agent that 45 
receives/sends Switched Circuit Network (SCN) native 
signaling at the edge of the IP network. Accordingly, in 
this context, the SG 104 operates as a signaling point 
(SP) that has both an IP interface used for the transport 
of SS7 over IP, and an interface to the conventional SS7 so 
network. 

[0022] A conventional SS7 protocol stack structure 
1 12 is provided at SEP 102 for effectuating SS7 signal- 
ing over the signaling path 106. Three Levels of MTP 
layers, MTP1 through MTP3 (reference numerals 1 14A 55 
through 1 14C, respectively), and one or more SS7 user 
parts such as Telephony User Part (TUP), Data User 
part (DUP), etc. (collectively referred to as SS7UP 



114D) are accordingly provided in conformity with 
known SS7 standards. 

[0023] The SG 104 is provided with a nodal inter- 
working function (NIF) 116 for interfacing between the 
SS7 and IP network portions. MTP1 and MTP2 form a 
portion of the SS7 protocol stack structure for effectuat- 
ing SCN's native signaling. In order to effectuate SS7- 
over-IP, an MTP2-User Adaptation (N2UA) layer 1 1 8C is 
provided as part of NIF 1 16 such that it interfaces to an 
SCTP layer 118B that sits on top of the underlying IP 
layer 1 1 8A. 

[0024] The MGC node 106 disposed in the IP net- 
work is provided with a protocol stack structure 120 to 
be operable with the SG 104 for effectuating the SS7- 
over-IP messaging via the IP path 110. The M2UA layer 
1 18C is included in the protocol stack structure 120 in 
order to interface to the SCTP layer 118B provided 
thereat. The upper SS7 layers, MTP3 layer 114C and 
SS7UP 1 14D, are also available as part of the protocol 
stack structure 120. 

[0025] Additional description regarding the various 
elements forming the network arrangement 1 00 and the 
operation of the M2UA layer for effectuating SS7-over- 
IP transport in the current architecture may be found in 
a "work in progress" Internet Draft titled "SS7 MTP2- 
User Adaptation Layer" (draft-ietf-sigtran-m2ua-04.txt) 
which can be accessed at the URL <http:/www. ietf.org) 
associated with the IETF. This work in progress Internet 
Draft is incorporated by reference herein. 
[0026] Those skilled in the art should realize upon 
reference hereto that solutions implementing the M2UA 
layer in relevant network elements (such as SGs, 
IPSPs, MGCs, et cetera) for facilitating SS7-over-IP 
involve the backhauling of signaling traffic through the 
IP network portion. That is, in the exemplary network 
arrangement described hereinabove, when a node such 
as the MGC 106 is required to process signaling mes- 
sages involving MTP2 layer functionality, the processing 
is not performed at the MGC. Rather, it is carried out by 
sending the signaling traffic to the SG node 1 04 overthe 
IP connection 110 for processing thereat and subse- 
quently receiving the processed messages by the MGC 
106 for SCTP transport. This backhauling operation 
introduces asymmetrical behavior at the two ends 
(SEP-SG end and SG-MGC end) of the SS7-IP inter- 
face as embodied by the SG 104. As alluded to in the 
Background section of the present patent application, 
such asymmetrical behavior introduces increased com- 
plexity relating to Operations and Administration of the 
additional link required for the backhauled signaling traf- 
fic. Furthermore, such additional links are in general 
unreliable because of the underlying IP-based transport 
employed, thereby compromising the overall reliability 
of the signaling network. 

[0027] FIG. 2 depicts an exemplary telecommuni- 
cations network 200 having an SS7 signaling network 
portion and an IP-based network portion, wherein the 
teachings of the present invention may be advanta- 
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geously practiced. Two SEP nodes 202A, 202B and a 
plurality of SS7 links or link sets associated therewith 
exemplify the SS7 signaling network portion. The IP- 
based network portion is exemplified by two IP-based 
SP nodes (IPSP 206A and 206B) and a packet- 5 
switched network (PSN) 208 operably associated there- 
with for providing IP-based SS7 message transport. 
Two SG nodes 204A, 204B are also included in the 
exemplary telecommunications signaling network 200, 
which are operable to provide SS7-IP interfaces to the w 
SEP nodes 202A and 202B, respectively. As will be 
described in greater detail hereinbelow, the various SG 
and IPSP nodes are provided with a peer-to-peer proto- 
col adaptation (PPA) structure for facilitating SS7-over- 
I P transport without backhauling the signaling traffic. 75 
[0028] As set forth above, the SEP nodes are oper- 
able with other nodes via SS7 link paths, of which link 
paths 210 disposed between the SEP and SG nodes 
are exemplary. The SG and IPSP nodes are coupled to 
the IP-PSN 208 via IP connection paths 212. As is well 20 
known, other nodes such as media gateways (MGWs), 
MGCs, et cetera, may also be included in the exemplary 
network 200. Moreover, the IPSP nodes are exemplary 
of various IP-interfaced nodes such as, e.g., IP signal- 
ing endpoints (IPSEPs), IP Signal Transfer Points 25 
(IPSTPs), IP Signal Switching Points (IPSSPs), IP Serv- 
ice Control Points (IPSCPs), and the like. 
[0029] FIGS. 3A and 3B depict two exemplary net- 
work portions wherein SS7 messages are transported 
over IP by utilizing a Level 2 MTP-User peer-to-peer 30 
adaptation (M2PA) layer provided in accordance with 
the teachings of the present invention. The M2PA layer 
may preferably be implemented as a PPA structure in 
software, hardware, firmware, or in any combination 
thereof at any suitable node such as an IPSP or SG 35 
described hereinabove. 

[0030] It should be recognized that the provisional 
patent application identified hereinabove and on which 
the priority of the present nonprovisional patent applica- 
tion is based includes a portion of a work in progress 40 
Internet Draft which refers to the M2PA layer as an 
"M2UA" layer although this layer's functionality is differ- 
ent from the functionality of the M2UA layer described 
hereinabove in reference to FIG. 1 . The "M2UA" nomen- 
clature was adopted in the work in progress Internet 45 
Draft at the time the provisional patent application was 
filed in order to be compliant with a broad umbrella 
"user adaptation" architecture then proposed under the 
IETF Some of the definitions used the work in progress 
document forming a portion of the provisional patent 50 
application have since been modified and the current 
version of the work in progress Internet Draft (draft- 
george-sigtran-m2peer-02.txt; incorporated by refer- 
ence herein) identifies the present invention's PPA func- 
tionality as M2PA and not M2UA. Accordingly, it should 55 
be understood that the "M2UA" functionality described 
as part of the provisional patent application referenced 
hereinabove is the same or essentially the same as the 



M2PA functionality described herein and is compre- 
hended within the PPA structure and functionality of the 
present nonprovisional application. 
[0031] Referring now in particular to FIG. 3A, the 
exemplary network portion 300A embodies two IPSP 
nodes 206A, 206B coupled together via an IP transport 
path 303 in a symmetrical peer-to-peer architecture for 
transporting SS7 messages in accordance with the 
teachings of the present invention. Each IPSP is pro- 
vided with a protocol stack structure 302 which com- 
prises an SS7 portion (a first structure) and an IP/SCTP 
portion (a second structure), wherein the PPA function- 
ality of the present invention is preferably provided in the 
form of an interworking M2PA layer between the MTP3 
layer and the SCTP layer. The M2PA layer thus operates 
so as to present the underlying SCTP layer at a node as 
a full MTP2 layer whose services can be used by the 
MTP3 layer at that node. 

[0032] The protocol stack structure 302 provided at 
each IPSP accordingly includes: IP layer 3 04 A, SCTP 
layer 304B, M2PA layer 304C, and MTP3 layer 304D. 
Those skilled in the art should recognize that although 
not explicitly shown in FIG. 3A, other SS7 layers such 
as the SCCP or User Parts (i.e., SS7UPs) may be 
present on top of the MTP3 layer 304D of the protocol 
stack structure 302. 

[0033] In order to achieve seamless interworking at 
the MTP3 layer by way of the M2PA layer, all the primi- 
tives between MTP3 and MTP2 are supported in the 
PPA structure as embodied in the M2PA layer of the 
present invention in a presently preferred exemplary 
implementation thereof. Accordingly, an SCTP associa- 
tion (described hereinbelow in greater detail) created 
between two IP nodes (e.g., IPSPs 206A and 206B) 
operates as a virtual SS7 link therebetween for the 
transport of the MTP3 messages. Further, because the 
MTP specification requires that each node with an 
MTP3 layer be represented by an SS7 point code, the 
IPSP nodes provided in accordance herewith also have 
a point code, respectively. 

[0034] FIG. 3B depicts another exemplary network 
portion 300B wherein the IP network elements are pro- 
vided with the M2PA layer functionality in accordance 
with the teachings of the present invention. As set forth 
above, SEP 202A is operably linked to SG 204A via the 
SS7 link path 210, and is provided with a conventional 
SS7 protocol stack structure 310. Accordingly, the pro- 
tocol stack structure 31 0 comprises the following layers 
in the exemplary embodiment depicted in FIG. 3B: 
MTP1 layer 306A, MTP2 layer 306B, MTP3 layer 304D, 
SCCP 306C, and TCAP 306D. 

[0035] The SG node 204A (which is essentially an 
IPSP equipped with both traditional SS7 and IP network 
connections) is provided with an interworking protocol 
stack structure 312 including the PPA functionality by 
way of the M2PA layer 304C. The MTP3 layer 304D is 
provided as a user of both MTP2 and M2PA layers so as 
to support the SS7 and IP interfaces. The MTP1 layer 
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306 A provided in the protocol stack structure 312 effec- 
tuates the signaling data link functionality required for 
establishing the SS7 link path 210. The SCTP and IP 
layers (reference numerals 304A and 304B, respec- 
tively) underlying of the M2PA layer 304C correspond- 5 
ingly effectuate the IP-based transport of the SS7 
messages in accordance with the SCTP protocol. 
[0036] The IPSP node 206A is coupled to the SG 
node 204A via the IP transport path 303 as described 
hereinabove with respect to FIG. 3 A. In accordance with 10 
the teachings of the present invention, a protocol stack 
structure 314 comprising the symmetrical M2PA func- 
tionality is provided at the IPSP node 206A as previ- 
ously described. Additional SS7 layers (SCCP 306C 
and TCAP 306D) are also included in the protocol stack 15 
structure for effectuating an IN/AIN-based service archi- 
tecture. 

[0037] Those skilled in the art should recognize that 
the exemplary network portions 300A and 300B are 
only illustrative of the various nodal arrangements that 20 
are possible. For example, some network configurations 
may involve IPSP nodes without traditional SS7 links 
that could use the protocol layers 
MTP3//M2 PA//SCTP//I P to route SS7 messages in a 
network with all IP links. In yet another example, two SG 25 
nodes may be connected over an IP network to form an 
SG mated pair similar to the way STPs are provisioned 
in traditional SS7 networks (i.e., provisioning redundant 
pairs for increased reliability). 

[0038] Referring now to FIG. 4A, depicted therein is 30 
an exemplary arrangement 400 of the various network 
elements where multiple signaling network configura- 
tions may be implemented in accordance with the 
teachings of the present invention. Two SG nodes 204A 
and 204B are exemplified. Preferably, the functionality 35 
of the SG nodes may be compartmentalized such that 
pure SS7 connectivity may be provided between them 
via a traditional SS7 path 210 (which could include addi- 
tional SS7 nodes disposed in a network). Accordingly, 
each SG node may be provided with a pure SS7 proto- 40 
col stack structure for effectuating such SS7 connectiv- 
ity. In FIG. 4A, reference numerals 41 2A and 41 2B refer 
to the pure SS7 protocol stack structures for nodes 
204A and 204B, respectively. 

[0039] Each SG node may further be provided with 45 
the symmetrical M2PA functionality of the present 
invention as part of its PPA structure for effectuating 
SS7-over-IP transport. Protocol stack structures 41 OA 
and 41 0B are accordingly provided at SG nodes 204A 
and 204 B, respectively, for effectuating the IP connec- 50 
tion path 212 therebetween. In addition, an MTP2/M2PA 
interface is provided at each SG node for effectuating 
MTP2 transport over IP via path 406, which transport 
does not involve MTP3 layer functionality. Reference 
numerals 408A and 408B exemplify such MTP2/M2PA 55 
interfaces provided with the SG nodes. 
[0040] A traditional SSP 403 with its associated 
protocol stack 31 0 is coupled to the SG node 204A via 



link 210 for effectuating SS7 signaling. In similar fash- 
ion, an SCP node 402 having a protocol stack 41 8 is 
provided to be operable with the SG node 204B via the 
traditional SS link 210. Accordingly, a conventional SS7 
signaling configuration involving the SSP and SCP 
nodes may be obtained by way of the coupled SG 
nodes. 

[0041] Each of the SG nodes 204A, 204B is also 
preferably coupled to one or more appropriate IP-com- 
pliant SP elements for forming SS7-over-IP signaling 
network configurations. Thus, IPSP 206A is provided to 
be operable with the interworking protocol stack 41 OA of 
the SG node 204A. In similar fashion, an IPSCP node 
404 is provided to be operable with the interworking pro- 
tocol stack 41 0B of the SG node 204B. 
[0042] Continuing to refer to FIG. 4A, the exemplary 
network arrangement 400 may preferably include an 
MGW node 414 coupled to the SG node 204A by 
means of the SS7 link path 210 which is effectuated 
using MTP1 and MTP2 layers. MGW 414 is operable to 
interface with a plurality of media such as, for example, 
Integrated Services Digital Network (ISDN) 426, Pri- 
mary Rate Interface (PRI) 428, and a modem 430. 
Accordingly, it should be appreciated that the access 
signaling protocol messaging associated with the 
ISDN/PRI media (e.g., Q.931), can be converted to the 
common channel SS7 messaging which may then be 
transported over the IP network in accordance with the 
teachings of the present invention. 
[0043] The SG node 204B is coupled to an IP-MGC 
node 41 6 having a protocol stack structure 422, wherein 
the interworking PPA functionality is embodied in the 
M2PA layer thereof. The IP connection path 212 dis- 
posed between the SG and MGC nodes carries out the 
SCTP-based SS7-over-IP transport. A connection path 
424 disposed between the MGW and MGC nodes is 
used for effectuating the transmission of the MGCP 
messaging over IP therebetween. 
[0044] Referring now to FIG. 4B, depicted therein is 
a link connection arrangement between two network 
nodes where multiple alternative links may be advanta- 
geously implemented in a network arrangement such as 
the arrangement 400 described hereinabove with 
respect to FIG. 4A. Nodes 460A and 460B represent 
any two network elements depicted in FIG. 4A. For 
example, node 460A may comprise an SEP or SCP. 
Similarly, an STP or SCP may be provided as node 
460B. Each node is provided with a link set which 
includes multiple links for the transport of SS7 mes- 
sages. In FIG. 4B, node 460A is exemplified with link set 
458A and node 460B is exemplified with link set 458B. 
[0045] As described in greater detail in the forego- 
ing, the link sets may be implemented using conven- 
tional SS7 configurations using SS7 link paths (e.g., 
reference numeral 210) or SS7-over-IP configurations 
involving links based on IP connection paths (e.g., refer- 
ence numeral 212). It should be appreciated that these 
configurations may involve one or more SS7 networks 
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(e.g., SS7 network 452) or one or more IP networks 
(e.g., internal IP network or intranet 454, leased exter- 
nal IP network or extranet 456). 

[0046] Continuing to refer to FIG. 4B, those skilled 
in the art should readily appreciate upon reference 5 
hereto that because of the multiple signaling network 
configurations available between the two nodes 460A 
and 460B, link failover or changeover (hereinafter 
"changeover," collectively) may be advantageously 
implemented in the exemplary nodal arrangement 450. w 
Further, such link ch an geover/fai lover (which can be 
from a traditional SS7 link to an SS7-over-IP link and 
vice versa) may be effectuated based on a number of 
considerations, e.g., Quality of Service (QOS), link reli- 
ability, bandwidth constraints, packet loss, link availabil- 15 
ity, traffic congestion, rate scheme(s) and service 
options/preferences, et cetera. The M2PA layer's func- 
tionality and relevant message flows for effectuating a 
link changeover will be set forth in greater detail in the 
subsequent portions of the Detailed Description. 20 
[0047] FIGS. 5A and 5B depict an example of the 
formation of an SCTP association between two nodes 
or endpoints disposed in a client-server relationship, 
which association is utilized for the transport of SS7 
messages over IP. As is well known, the SCTP protocol 25 
is preferably provided as a reliable, connection-oriented 
transport protocol operating on top of a connectionless 
packet switched network such as an IP network, and 
may be viewed as a layer between an SCTP user appli- 
cation (referred to as "SCTP user," which in the context 30 
of the present patent application comprises the M2PA 
layer structure) and the underlying connectionless IP 
network. The basic service offered by SCTP is the relia- 
ble transfer of user messages between peer SCTP 
users by means of an association between two SCTP 35 
endpoints. Because SCTP provides in-sequence deliv- 
ery, related functionality may be removed from the 
MTP2 functionality. Accordingly, the M2PA layer (operat- 
ing as the SCTP user) does not necessarily have to 
include such related functionality. However, since SCTP 40 
does not provide functions related to MTP2 layer's Link 
State Control, these functions are included in the func- 
tionality of the M2PA layer. 

[0048] In orderto support peer-to-peer communica- 
tion using SCTP, MTP2 layer's Message Signal Units 45 
(MSUs) are passed by M2PA to SCTP as User Data 
messages for transport across a link. Also, MTP2 layer's 
Link Status Signal Units (LSSUs) (which allow peer 
MTP2 layers to exchange status information) are 
passed by M2PA as Link Status messages. On the 50 
other hand, the M2PA layer need not generate any spe- 
cial messages for the transport of MTP2 layer's Fill-In 
Signal Units (FISUs), as these are typically sent when 
no other SS7 signal units are waiting to be sent, and this 
purpose is served by the heartbeat messages provided 55 
in SCTP. In addition, because the message acknowl- 
edgment functionality of the FISUs is also addressed by 
SCTP, such functionality may not be needed in the 



M2PA layer. 

[0049] As is well known, Transmit Sequence Num- 
bers (TSNs) are used by SCTP for reliable delivery of 
messages. Further, SCTP uses Stream Sequence 
Numbers (SSNs) for effectuating sequential delivery of 
messages within each stream. On the other hand, the 
MTP2 layer uses Forward and Backward Sequence 
Numbers (FSNs/BSNs) for message sequencing, which 
are of different size than the TSN/SSNs supported by 
SCTP. Accordingly, the M2PA functionality includes 
mapping between the TSN/SSNs and FSN/BSNs, 
wherein appropriate modular conversion procedures 
are employed. 

[0050] Because SCTP uses larger sequence num- 
bers than MTP, the MTP3 layer's Changeover proce- 
dure preferably uses the Extended Changeover Order 
(XCO) and Extended Changeover Acknowledgment 
(XCA) messages as described in the ITU Recommen- 
dation Q.2210, incorporated by reference herein. The 
use of SCTP SSNs is particularly described in the con- 
text of link changeover procedures set forth hereinbe- 
low. 

[0051] Pursuant to the formation of an association, 
each SCTP endpoint provides the other endpoint with a 
list of transport addresses (e.g., one or more IP 
addresses in combination with an SCTP port) through 
which that endpoint can be reached and from which it 
will originate SCTP packets. The association spans 
transfers over all of the possible source/destination 
combinations which may be generated from each end- 
point's lists. Additional details regarding SCTP architec- 
ture may be found in the work in progress Internet Draft 
identified as (draft-ietf-sigtran-sctp-13.txt) which is incor- 
porated by reference herein. 

[0052] Continuing to refer to FIG. 5A, a client node 
502 and a server node 504 are provided in the exem- 
plary network arrangement 500A. To prevent duplicate 
associations from being established, the client/server 
relationship is determined in advance. That is, it is 
decided beforehand as to which endpoint initiates the 
establishment of an association (i.e, operates as a cli- 
ent). The other endpoint is of the endpoint pair operates 
as the server. It should be realized that an endpoint may 
be a client in its relationship with one endpoint, and a 
server in its relationship with another endpoint. 
[0053] The client 502 initiates the association using 
the server's IP address and the M2PA structure's port 
number as the destination endpoint. In orderto allow for 
multiple links between the two endpoints, the client uses 
a different local port number for each link. Preferably, it 
is decided in advance which local ports are to be used 
by the client. During the initialization in accordance with 
the SCTP procedures, addresses of the client ports are 
made available to the server 504. Each combination of 
client IP address/port and server IP address/port 
uniquely identifies an association between the two end- 
points. And, each association is mapped to the same 
Signaling Link Code (SLC) in the client and server, 
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which defines a common reference number for a link 
between two peer MTP3 entities. 
[0054] Accordingly, based on the foregoing, it 
should be realized that a link is preferably implemented 
as an SCTP association identified by two endpoints, a 5 
client and server, wherein each endpoint is identified by 
an IP address and port number. Each association, in 
turn, corresponds to an SLC. As depicted in FIG. 5A, 
IRA and IPB refer to the two IP addresses of the client 
and server, respectively. P1 and P2 refer to the pre- 10 
selected port numbers for the client (wherein reference 
numerals 506 and 508 exemplify the client ports) and 
PW refers to the port number for M2PA (wherein refer- 
ence numeral 510 exemplifies the M2PA port). A first 
SCTP association 51 4A (identified as SLC=a) is thus 15 
established using the combination IPA/P1 and IPB/PW. 
A second SCTP association 51 4B (identified as SLC=b) 
is similarly established between the endpoints using the 
combination IPA/P2 and IPB/PW. These source/desti- 
nation address combinations are provided as a table 20 
500Bin FIG. 5B. 

[0055] Each association preferably contains two 
streams in each direction (not shown). In a presently 
preferred exemplary embodiment of the present inven- 
tion, Stream 0 is designated for Link Status messages, 25 
whereas Stream 1 is designated for User Data mes- 
sages. 

[0056] If SCTP fails to establish an association after 
the M2PA has received a Start command from its MTP3 
layer, the M2PA preferably responds by reporting that 30 
the link is out of service. If the M2PA has an association 
ID for that association, it may be aborted thereafter by 
using an Abort primitive. Once the association is estab- 
lished, the M2PA layer invokes a GetSRTTReport prim- 
itive to determine a Smooth Round Trip Time (SRTT) 35 
parameter from SCTP. If the SRTT parameter is found 
to be satisfactory and the link has not been deactivated 
by the MTP3 layer, various link management proce- 
dures are carried out to verify the link's integrity. There- 
after, the signaling bearer traffic is loaded or placed onto 40 
the link for transport. 

[0057] FIG. 5C depicts a flow chart which summa- 
rizes the steps involved in an exemplary method for 
transporting SS7 messages in accordance herewith. A 
virtual link is established over an IP connection by 45 
means of an SCTP association as described herein- 
above (step 540). Upon verifying the virtual link's integ- 
rity (step 542), the SS7 messages are converted to an 
SCTP stream of signaling bearer traffic (step 544). The 
virtual link is loaded with the traffic thereafter for trans- so 
port to the destination endpoint (step 546). 
[0058] To seamlessly effectuate the symmetrical 
peer-to-peer protocol adaptation functionality as 
described hereinabove, the following services are pro- 
vided by the M2PA functionality: 55 

- The SS7 MTP3/MTP2 (i.e., MTP2 - user) interface 
is retained at the termination point in the IP net- 



work; 

The M2PA layer provides the equivalent set of serv- 
ices to its user as provided by MTP2 to MTP3; 

Support for MTP3/MTP2 interface boundary; and 

Support for peer-to-peer communication. 

[0059] The M2PA functionality includes the follow- 
ing: 

Mapping: For each IP link, the M2PA layer main- 
tains a map of the SS7 link to its SCTP association 
and its corresponding IP destination; 

SCTP Stream Management: SCTP allows a user- 
specified number of streams to be opened during 
the initialization. It is the responsibility of the M2PA 
layer to ensure proper management of the streams 
associated within each association; and 

Retention of MTP3: The M2PA layer allows MTP3 
to perform all of its Message Handling and Network 
Management functions with IPSPs as with other 
SS7 nodes. 

[0060] In a presently preferred exemplary embodi- 
ment of the present invention, the protocol messages 
for M2PA are preferably provided with a message 
header structure which contains a version, message 
type, and message length. This message header is 
preferably provided to be common among all PPA struc- 
tures in a network. As pointed out in the foregoing sec- 
tions, the M2PA layer supports two types of messages: 
User Data messages (corresponding to the MSUs) and 
Link Status messages (corresponding to the LSSUs). In 
MTP, LSSUs have priority over MSUs. To accommodate 
this priority in M2 PA functionality, Link Status and User 
Data messages are sent via SCTP on separate streams 
as described in the SCTP association formation above. 
[0061] Referring now to FIGS. 6A and 6B, depicted 
therein are various message flows for effectuating the 
M2PA layer structure in accordance with the teachings 
of the present invention. Message flows among the var- 
ious layers (which layers are illustrated as distinct "inter- 
layer message nodes" for the sake of clarity) of a proto- 
col stack structure provided at an IPSP node (e.g., node 
206A) are exemplified. 

[0062] Message flow portion 606A illustrates basic 
message transmission and reception between MTP3 
602A and M2PA 603A. Messages are transmitted using 
a Data Request primitive 608 from MTP3 602A to M2PA 
603A. Messages are received using a Data Indication 
primitive 610 from M2PA 603A to MTP3 602A. 
[0063] When MTP3 602A sends a message for 
transmission to M2PA 603A, M2PA 603A adds the 
M2PA header to the message and passes it to SCTP 
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604A using a Send primitive 609. When M2PA 603A 
receives a Data message 611 from SCTP 604A, it 
removes the header and passes the message to MTP3 
602A. 

[0064] Message flow portion 606B illustrates mes- 
sages for effectuating link status indication. Upon 
receiving a Communication Up message 612 from 
SCTP 604A, M2PA performs link proving (step 614). 
Thereafter, a Link_ln_Service message 614 is transmit- 
ted by M2PA 603A to MTP3 602A. In response to a 
Communication Lost message 616 is received from 
SCTP 604A, M2PA 603A sends a Link_Out_Of_Service 
message 618 to MTP3 602A. 

[0065] The MTP3 layer in an IPSP node can 
request that an SS7 link be brought into alignment using 
normal or emergency procedures. During normal align- 
ment, communication to the other endpoint is tested for 
a period of time in order to ensure that the communica- 
tion link satisfies certain performance requirements 
such as, e.g., the SRTT/RTT and packet loss. Normal 
alignment is used when there are other links associated 
with the affected link, wherein the other links are opera- 
ble to the same destination. Emergency alignment is 
used when there are no other links to the same destina- 
tion. During emergency, the link is not tested for a "long" 
period of time, but instead an indication from SCTP is 
used to bring the link in-service. 

[0066] An example of the message flow to bring an 
SS7 link in-service using the normal alignment proce- 
dure is shown in message flow portion 606C. Link align- 
ment is established when MTP3 602A sends a Start 
message 620 to M2PA 603A. To begin alignment in 
M2PA 603A, M2PA sends an Associate primitive (not 
shown) to SCTP 604A if the SCTP association is not 
already established. Responsive to the Start message 
620, M2PA 603A transmits an Establish Response 622 
to MTP3 602A. 

[0067] An example of the message flow to bring an 
SS7 link in-service using the emergency alignment pro- 
cedure is provided in message flow portion 606D. A Sta- 
tus Emergency Request 624 is transmitted from MTP3 
602A to M2PA 603A. A Status Response 626 is pro- 
vided responsive thereto. An Establish_Start Request 
628 is subsequently sent from MTP3 602A to M2PA 
603A. Responsive thereto, M2PA 603A transmits an 
Establish Response 630 to MTP3 602A. It should be 
noted, however, that once an Emergency Request is 
transmitted and accepted using a channel (link), that 
condition remains on that channel until an Emergency 
Ceased message is received or a Management Chan- 
nel Reset message. 

[0068] Message flow portion 606E exemplifies 
messages for effectuating link proving during emer- 
gency. Upon receiving an Emergency notification 632 
from MTP3 602A, link proving in M2PA 603A is disabled 
(step 634). When a Communication Up message 636 is 
received from SCTP 604A, M2PA 603A responds by 
propagating a Status request 638 to SCTP 604A in 



order to ensure that a performance parameter (e.g., 
SRTT/RTT) satisfies the requirements of the particular 
communication application. After verifying the link integ- 
rity, a Link_ln_Service 640 is sent from M2PA 603A to 

5 MTP3 602A. 

[0069] Message flow portion 606F exemplifies mes- 
sages for effectuating link proving when emergency is 
ceased. Upon receiving an Emergency Ceased notifica- 
tion 642 from MTP3 602A, link proving in M2PA 603A is 

10 enabled (step 644). After receiving a Communication 
Up message 646 from SCTP 604A, M2PA 603A 
responds by transmitting Status SRTT/RTT messages 
648 to SCTP 604A for a predetermined time duration 
(e.g., 3 seconds). Subsequent to verifying that the 

15 SRTT/RTT values satisfy applicable performance 
requirements, a Link_ln_Service 650 is transmitted to 
MTP3 602 A from M2PA 603 A. 

[0070] FIGS. 7-14 depict message flow diagrams 
for effectuating various exemplary M2PA procedures 
20 involving a link disposed between two nodes, e.g., end- 
points 206A and 206B, wherein appropriate protocol 
layers are once again provided as "inter-layer message 
nodes" for illustrative purposes. 

[0071] Referring in particular to FIG. 7, depicted 

25 therein is a message flow diagram which illustrates 
messages for effectuating link initialization involving 
endpoints 206A and 206B. It should be appreciated that 
the messages exemplified in FIG. 7 are essentially sim- 
ilar to the messages exemplified in some of the mes- 

30 sage flow portions described hereinabove with respect 
to FIGS. 6A - 6B. Accordingly, only the pertinent fea- 
tures are highlighted in detail herein. 
[0072] The message flow depicted in FIG. 7 pro- 
vides an example of the message flow to bring an SS7 

35 link in-service. While proving is done by both ends of the 
link, it is shown for one node only (node 206A) for the 
sake of simplicity. An Out_Of_Service message 702 
propagated between M2PA 603A and MTP3 602A indi- 
cates that the link between nodes 206A and 206B is 

40 taken out of service. An Emergency or Emergency 
Ceases message 704 is sent from MTP3 602A to M2PA 
603A, as the case may be, in order to commence a suit- 
able alignment procedure as described above. A Start 
message 706 from MTP3 602A to M2PA 603A initiates 

45 the process. Responsive to the Start message, M2PA 
603A sends an Associate primitive 708 to SCTP 604A. 
Thereafter, SCTP 604A engages in a suitable SCTP 
association procedure 710 with its peer SCTP 604B in 
node 206B. Upon successful formation of an associa- 

50 tion between SCTP 604A and 604B, a Communication 
Up message 712 is propagated from each SCTP back 
to its M2PA. 

[0073] FIG. 8 depicts a message flow diagram for 
effectuating link confirmation after the SCTP associa- 
55 tion is established. It should be appreciated that even 
though an SCTP association may have been estab- 
lished, it is important that M2PA not send MTP3 data at 
this point until it is confirmed that both ends of the link 
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are ready for traffic. Otherwise, messages could be lost. 
The link is confirmed for traffic when the endpoints 
exchange ln_Service messages. Upon initiating a Get- 
SRTTReport primitive 802 from M2PA 603A to its SCTP 
604A, a peer-to-peer exchange of 
Link_Status_ln_Service messages 804 and 806 is car- 
ried out between M2PA 603A in node 206A and M2PA 
603B in node 206B. Thereafter, an ln_Service message 
808 is propagated from M2PA 603Ato its MTP3 602Ato 
indicate that the link is ready for traffic. At this point, 
MTP3 602A may begin sending data messages. 
[0074] FIG. 9 depicts a message flow diagram for 
effectuating end-to-end message transmission and 
reception. As set forth in reference to the message flow 
portions depicted in FIGS. 6A and 6B, appropriate 
transmission and reception primitives are used between 
MTP3 and M2PA. Upon receiving a message for trans- 
mission via a suitable primitive 902 from MTP3 602A, 
M2PA 603A generates a Send primitive 904 to its SCTP 
604A including the data message. Thereafter, SCTP 
604A transports the message to its peer SCTP 604B in 
node 206B using known SCTP procedures 906. SCTP 
604B transmits a Receive primitive 908 to its M2PA 
603B with the data message. The received data mes- 
sage is then sent to MTP3 602B via a Data Indication 
primitive 910. 

[0075] FIG. 1 0 depicts a message flow diagram for 
effectuating link status indication. When SCTP 604A 
detects a communication loss 1 002 (due to, e.g., loss of 
association, etc.), it sends a Communication Lost primi- 
tive 1004 to its M2PA 603A. Preferably, the detection is 
effected at a client node in the client/server pair. Upon 
receiving the Communication Lost primitive 1004, M2PA 
603A notifies MTP3 that the link is out of service. An 
Out_Of_Service primitive 1 006 is used for this purpose. 
[0076] FIG. 1 1 depicts a message flow diagram for 
indicating processor outage. Preferably, a processor 
outage is deemed to exist when M2PA cannot transfer 
messages because of a condition at a higher layer than 
M2PA. When M2PA 603A detects a local processor out- 
age (step 1 102), it sends a Link Status Processor Out- 
age message 1 104 to its peer M2PA 603B, with status 
being Processor Outage. This message flow is effectu- 
ated via SCTP messaging 1106 and Receive primitive 
1108 between SCTP 604B and M2PA 603B. The peer 
M2PA (i.e., M2PA 603B in this example), upon receiving 
the Link Status Processor Outage message, reports 
Remote Processor Outage 1 1 1 0 to its MTP3 602B. The 
M2PAs discard any messages received and also cease 
sending messages. When the processor outage 
ceases, MTP3 602A sends a Local Processor Recov- 
ered indication 1 1 1 1 to the local M2PA, i.e., N2PA 603A. 
The local M2PA notifies its peer by sending Link Status 
message 1112, with status being Processor Outage 
Ended. Again, this is effectuated via SCTP messaging 
1114 and Receive primitive 1116 between SCTP 604B 
and M2PA 603B. In response, M2PA 603B notifies its 
MTP3 602B that the remote processor outage has 



ceased (message 1118). 

[0077] FIG. 12 depicts a message flow diagram for 
effectuating congestion notification. When SCTP 604A 
detects congestion 1202 or, depending upon implemen- 

5 tation, when M2PA 603A notices repeated failures to 
Send requests to its SCTP, an indication of congestion 
onset 1204 is reported to M2PA 603A. MTP3 602A is 
then notified of link congestion by a Congestion Onset 
1206 (Link_Congested primitive). If the congestion con- 

w dition exceeds a predetermined period of time, MTP3 
602A may take the link out of service (by means of a 
Stop message, for example). 

[0078] Indication of congestion abatement is also 
implementation-specific. SCTP may detect a conges- 

15 tion abatement condition 1208 and then notify M2PA 
603A (via indication 1210). Also, M2PA 603A may poll 
the status of its SCTP by transmitting a plurality of Sta- 
tus messages over a period of time. Successful trans- 
mission of the Status messages may indicate 

20 congestion abatement 1210. Upon determining abate- 
ment, M2PA 603A notifies MTP3 602A of congestion 
abatement 1212 (Link_Congestion_Ceased primitive). 
[0079] FIG. 13 depicts a message flow diagram for 
effectuating link deactivation upon issuing a Stop mes- 

25 sage 1302 from MTP3 602A to its M2PA 603A. In 
response, M2PA 603A sends an Abort message 1304 
to SCTP 604A. Subsequently, SCTP 604A engages in a 
known termination process 1306 so that its association 
with peer SCTP 604B is deactivated. Thereafter, SCTP 

30 604A generates a Communication Lost primitive 1308 
to its M2PA 603A, which issues an Out_Of_Service 
primitive to MTP3 602A. 

[0080] FIG. 14 depicts a message flow diagram for 
effectuating link changeover/fai lover in accordance with 

35 the teachings of the present invention. As may be read- 
ily appreciated, the objective of the changeover is to 
ensure that signaling traffic carried by the unavailable 
signaling link (due to congestion, packet loss, link fail- 
ure, etc.) is diverted to an alternative signaling link as 

40 quickly as possible while avoiding message loss, dupli- 
cation, or mis-sequencing. Accordingly, the presently 
preferred exemplary embodiment of the present inven- 
tion includes data retrieval as part of the changeover 
procedure, which is performed before opening the alter- 

45 native signaling link or links. 

[0081] Data retrieval comprises the following steps: 

buffer updating, that is, identifying all those mes- 
sages (e.g., User Data messages) in the retrans- 
so mission buffer of the unavailable link which have not 
been received by the remote SCTP, as well as 
untransmitted messages, and 

transferring those messages to the transmission 
55 buffers of the alternative links. 

[0082] In order to support changeover in M 2 PA, the 
SCTP sequence numbers are used in place of the SS7 
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protocol's FSNs and BSNs. For the purposes of the 
present invention, SCTP sequence numbers and SS7's 
FSNs/BSNs will be collectively referred to as "message 
sequence numbers." As alluded to hereinbefore, SSNs 
used by SCTP are 16 bits long while MTP2's 
FSNs/BSNs are 7-bit values. Accordingly, XCO and 
XCA messages are utilized rather than the Changeover 
Order (COO) and Changeover Acknowledgment (COA) 
messages. 

[0083] For data retrieval, MTP3 requests a BSN 
from its M2PA. This is the sequence number of the last 
message received by the local endpoint. Normally, 
SCTP delivers ordered messages to the MTP applica- 
tion. However, during congestion or failure condition, 
the sequence numbers of the acknowledged messages 
may have gaps. In particular, the Selective Acknowledg- 
ment (SACK) message(s) can have several of such 
gaps. Accordingly, it is preferable to scan through these 
gaps and find the sequence number before the first gap. 
For reliable reconstruction of the transmission, this is 
the sequence number from which the remote endpoint 
has to transmit the messages. Therefore, this sequence 
number is identified as the BSN by the local endpoint 
and communicated to the other endpoint (i.e., the 
remote endpoint). In a similar fashion, the remote end- 
point also detects a BSN from its end and communi- 
cates it to the local endpoint. Once the local endpoint's 
MTP receives this BSN, it retrieves all the unacknowl- 
edged messages starting from this number. This 
retrieval is accomplished through a Retrieval Request 
and FSNC request, where FSNC equals BSN from the 
XCA message. After all the messages are sent from 
M2PA to MTP3 at the local end, a Retrieval Complete 
indication is sent. 

[0084] It should be recognized that the sequence 
numbers and messages requested by MTP3 may be 
obtained by M2PA from SCTP via a Communication 
Lost primitive. In this alternative approach, it is neces- 
sary that SCTP be provided with the message retrieval 
capability. Accordingly, the SSNs of the messages need 
to be identified and SCTP may be required to retain the 
messages for a predetermined time in order for retrieval 
by MTP3/M2PA whenever an association is aborted. 
Subsequently, SCTP must be able to return messages 
to its upper layer (i.e., M2PA) by means of appropriate 
stream(s), and based on SSNs. 

[0085] If M2PA receives a Retrieve BSNT request 
from MTP3, M2PA responds with a BSNT indication. 
The BSNT value is the SCTP SSN of the last message 
received by SCTP User Data stream before any gaps in 
its SSNs. If there are any messages with an SSN 
greater than this BSNT value have been acknowledged 
by SCTP but not have been passed up to M2PA, such 
messages need to be retransmitted by the far end on an 
alternative link. 

[0086] If M2PA retrieves a Retrieval Request and 
FSNC request from its MTP3, M2PA retrieves from 
SCTP the following: 



(A) any transmitted messages beginning with the 
first acknowledged message with SSN greater than 
FSNC; and 

5 (B) any untransmitted messages in SCTP. 

[0087] Each of these messages is sent to MTP3, 
preferably in the order of (A) and then (B). Thereafter, as 
alluded to before, M2PA sends a Retrieval Complete 

10 indication to MTP3. 

[0088] The message flow depicted in FIG. 14 exem- 
plifies the foregoing procedures in a message flow dia- 
gram, wherein the local and far endpoints are illustrated 
by nodes 206A and 206B, respectively. Upon receiving 

15 a Communication Lost primitive 1402 from SCTP 604A, 
M2PA 603A sends an Out_Of_Service primitive 1404 to 
MTP3 602A. Subsequently, a Retrieve BSN request 
1406 is issued to M2PA 603, whereupon M2PA locates 
the first gap in the received messages (step 1408), as 

20 explained in the foregoing. The BSN is then communi- 
cated to MTP3 602A via an Indicate BSN primitive 
1410. 

[0089] An XCO message 1412 on another link is 
communicated by MTP3 602A to its peer in the far end- 

25 point, i.e., MTP3 602B, with the BSN value. The remote 
MTP3 602B sends a Retrieve BSN request to its M2PA 
1414 which then responds with a BSN indication 1416. 
An XCA message 141 8 with the BSN retrieved from the 
remote M2PA 603B is then exchanged with the local 

30 MTP3 602A. 

[0090] A Retrieval Request and FSNC request 
1420 is then forwarded to M2PA 602A at the local end. 
As pointed out before, FSNC equals the BSN value 
received from the far end via the XCA message 1418. 

35 Subsequently, M2PA locates the first gap in the 
acknowledgment messages (step 1422) and re-sends 
the messages from there on (retrieved messages 
1424). Upon completion of retransmission, a Retrieval 
Complete indication 1426 is communicated to MTP3 

40 602A, which may transmit the messages on another 
link. 

[0091 ] Based on the foregoing, it should be appreci- 
ated that the present invention advantageously provides 
a symmetrical peer-to-peer protocol adaptation solution 

45 for facilitating the transport of SS7-over-l P which avoids 
the shortcomings and deficiencies of the state-of-the 
art. A high speed IP link may be maintained between 
two SS7 nodes, e.g., between SEP/STP and STP/SCP 
combinations, in order to take advantage of the packet 

50 transport mechanism while still ensuring carrier-grade 
connectivity and reliability. The PPA structure and func- 
tionality as embodied in the M2PA layer may be pro- 
vided to enhance the functionality of existing STPs for 
supporting Voice-over- 1 P. In particular, nodes or net- 

55 work elements such as, e.g., Signaling Gateways, 
Access Gateways, Trunking Gateways, other Media 
Gateways and Media Gateway Controllers, may be pro- 
vided with additional functionality in accordance with the 
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teachings of the present invention for the provisioning of 
known and heretofore unknown IN/AIN-based services, 
involving voice, data, video, audio, interactive multi- 
media, and the like, over IP-based networks. 
[0092] It is believed that the operation and construe- 5 
tion of the present invention will be apparent from the 
foregoing Detailed Description. While the apparatus 
and method shown and described have been character- 
ized as being preferred, it should be readily understood 
that various changes, modifications and enhancements w 
could be made therein without departing from the scope 
of the present invention as set forth in the following 
claims. 

Claims 15 

1. A telecommunications network element, compris- 
ing: 

a first structure operable to effectuate signaling 20 
communication over a signaling network using 
a signaling protocol; 

a second structure operable to transport said 
signaling communication across a packet- 25 
switched network using an Internet Protocol 
(IP)-based transport protocol, said IP-based 
transport protocol including a plurality of IP- 
based messages; and 

30 

a peer-to-peer protocol adaptation (PPA) struc- 
ture associated with said first and second 
structures, said PPA structure operating to con- 
vert said signaling communication between 
said signaling protocol and said IP-based mes- 35 
sages, said PPA structure including functional- 
ity to facilitate said first structure to locally 
process said signaling protocol's signaling 
messages. 

40 

2. The telecommunications network element as set 
forth in claim 1, wherein said signaling protocol 
comprises an access signaling protocol. 

3. The telecommunications network element as set 45 
forth in claim 2, wherein said access signaling pro- 
tocol comprises Q.931 protocol associated with at 
least one of an Integrated Services Digital Network 
(ISDN) and Primary Rate Interface (PRI) media. 

50 

4. The telecommunications network element as set 
forth in claim 1, wherein said signaling protocol 
comprises a common channel signaling protocol. 

5. The telecommunications network element as set 55 
forth in claim 4, wherein said common channel sig- 
naling protocol comprises Signaling System No. 7 
(SS7) protocol associated with switched circuit net- 



work. 

6. The telecommunications network element as set 
forth in claim 5, wherein said switched circuit net- 
work comprises a wireline telephony network. 

7. The telecommunications network element as set 
forth in claim 5, wherein switched circuit network 
comprises a wireless telephony network. 

8. The telecommunications network element as set 
forth in claim 5, wherein said IP-based transport 
protocol comprises Stream Control Transmission 
Protocol (SCTP). 

9. The telecommunications network element as set 
forth in claim 8, wherein said PPA structure 
includes means to convert transmission sequence 
numbers used by said SCTP protocol to message 
sequence numbers used by said SS7 protocol. 

10. The telecommunications network element as set 
forth in claim 9, wherein said message sequence 
numbers used by said SS7 protocol include forward 
sequence numbers. 

11. The telecommunications network element as set 
forth in claim 9, wherein said message sequence 
numbers used by said SS7 protocol include back- 
ward sequence numbers. 

12. The telecommunications network element as set 
forth in claim 8, wherein said PPA structure 
includes means for generating User Data mes- 
sages based on Message Signal Units provided by 
said SS7 protocol, said User Data messages being 
operable to be transported by using said SCTP pro- 
tocol. 

13. The telecommunications network element as set 
forth in claim 8, wherein said PPA structure 
includes means for generating Link Status mes- 
sages based on Link Status Signal Units provided 
by said SS7 protocol, said Link Status messages 
being operable to be transported by using said 
SCTP protocol. 

14. The telecommunications network element as set 
forth in claim 8, wherein said PPA structure 
includes mapping means to maintain a map 
between an SS7 communication link and its corre- 
sponding SCTP association. 

15. A telecommunications network, comprising: 

a first network portion operable to transport sig- 
naling messages using Signaling System No. 7 
(SS7) protocol; 
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a second network portion based on Internet 
Protocol (IP), said second network portion 
being operable to transport said signaling mes- 
sages using Stream Control Transmission Pro- 
tocol (SCTP); and 

a signaling gateway disposed between said 
first and second network portions, said signal- 
ing gateway including a peer-to-peer protocol 
adaptation (PPA) structure operable to inter- 
work between said SS7 protocol and SCTP 
messaging, wherein said PPA structure pro- 
vides a Level 2 Message Transfer Part (MTP2) 
interface between a Level 3 MTP (MTP3) layer 
of said SS7 protocol and said SCTP protocol, 
said PPA structure including functionality to 
locally process functions associated with an 
MTP2 layer. 

16. The telecommunications network as set forth in 
claim 1 5, wherein said signaling gateway is coupled 
to a signaling endpoint (SEP) disposed in said first 
network portion. 

17. The telecommunications network as set forth in 
claim 1 5, wherein said signaling gateway is coupled 
to a Signal Transfer Point (STP) disposed in said 
first network portion. 

18. The telecommunications network as set forth in 
claim 1 5, wherein said signaling gateway is coupled 
to a Signal Switching Point (SSP) disposed in said 
first signaling network. 

19. The telecommunications network as set forth in 
claim 1 5, wherein said signaling gateway is coupled 
to an IP-signaling point (IPSP) disposed in said 
second network portion. 

20. The telecommunications network as set forth in 
claim 19, wherein said IPSP comprises an IP- 
based Service Control Point (IPSCP). 

21. The telecommunications network as set forth in 
claim 19, wherein said IPSP comprises an IP- 
based signaling endpoint (IPSEP). 

22. The telecommunications network as set forth in 
claim 1 5, wherein said signaling gateway is coupled 
to a media gateway controller (MGC) disposed in 
said second network portion. 

23. An Internet Protocol (IP)-based telecommunica- 
tions network for transporting Signaling System No. 
7 (SS7) signaling information to effectuate an Intel- 
ligent Network (IN)-capable service architecture, 
comprising: 



a first IP signaling point (IPSP) having a Level 3 
Message Transfer Part (MTP3) functionality 
associated therewith; 

5 a second IP signaling point (IPSP) having a 

Level 3 Message Transfer Part (MTP3) func- 
tionality associated therewith; 

an IP-based virtual link coupling said first and 
w second IPSPs, said IP-based virtual link being 

operable to propagate messages using Stream 
Control Transmission Protocol (SCTP); and 
each of said first and second I PSPs including a 
peer-to-peer protocol adaptation (PPA) struc- 
15 ture operable to interwork between corre- 

sponding IPSP's MTP3 functionality and said 
SCTP protocol, wherein said PPA structure 
provides a Level 2 Message Transfer Part 
(MTP2) interface to said MTP3 functionality, 
20 said PPA structure including functionality to 

locally process functions associated with said 
MTP2 interface. 

24. The IP-based telecommunications network for 
25 transporting SS7 signaling information as set forth 

in claim 23, wherein said first IPSP comprises an IP 
signaling endpoint (IPSEP). 

25. The IP-based telecommunications network for 
30 transporting SS7 signaling information as set forth 

in claim 23, wherein said second IPSP comprises 
an IP Service Control Point (IPSCP). 

26. The IP-based telecommunications network for 
35 transporting SS7 signaling information as set forth 

in claim 23, wherein said first I PSP comprises a sig- 
naling gateway disposed in an SS7 signaling net- 
work. 

40 27. The IP-based telecommunications network for 
transporting SS7 signaling information as set forth 
in claim 23, wherein said second IPSP comprises 
an IP media gateway controller (MGWC). 

45 28. The IP-based telecommunications network for 
transporting SS7 signaling information as set forth 
in claim 23, wherein said second IPSP comprises 
an IP Signal Transfer Point (IPSTP). 

so 29. A method of transporting Signaling System No. 7 
(SS7) signaling information over an Internet Proto- 
col (IP)-based network, comprising the steps of: 

establishing a virtual link across an IP connec- 
55 tion between two nodes, said virtual link being 

operable to propagate messages using Stream 
Control Transmission Protocol (SCTP); 
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verifying said virtual link's integrity by one of 
said two nodes; 

interworking, at each of said two nodes, 
between a Level 3 Message Transfer Part 5 
(MTP3) functionality and said SCTP protocol 
by a peer-to-peer protocol adaptation (PPA) 
structure provided thereat, said PPA operating 
to convert SS7 signal bearer traffic into a 
stream of SCTP messages; and 10 



loading said virtual link with said stream of 
SCTP messages for propagation between said 
two nodes over said virtual link. 

30. The method of transporting SS7 signaling informa- 
tion over an IP-based network as set forth in claim 
29, further comprising the steps of: 



propagating said signal bearer traffic over said 
alternative link. 

31. The method of transporting SS7 signaling informa- 
tion over an IP-based network as set forth in claim 
30, wherein said alternative link comprises an IP- 
based link. 

32. The method of transporting SS7 signaling informa- 
tion over an IP-based network as set forth in claim 
30, wherein said alternative link comprises an SS7 
link. 

33. The method of transporting SS7 signaling informa- 
tion over an IP-based network as set forth in claim 
29, wherein one of said two nodes comprises an IP 
Signal Transfer Point (IPSTP). 

34. The method of transporting SS7 signaling informa- 
tion over an IP-based network as set forth in claim 
29, wherein one of said two nodes comprises an IP 
signaling endpoint (IPSEP). 

35. The method of transporting SS7 signaling informa- 
tion over an IP-based network as set forth in claim 
29, wherein one of said two nodes comprises an IP 
Service Control Point (IPSCP). 

36. The method of transporting SS7 signaling informa- 
tion over an IP-based network as set forth in claim 
29, wherein one of said two nodes comprises an IP 



media gateway controller (MGWC). 

37. A computer-accessible medium operable with a sig- 
naling node, said computer-accessible medium 
carrying a sequence of operations which, when 
executed by a processing entity associated with 
said signaling node, causes said signaling node to 
perform the steps of: 

establishing a virtual link across an IP connec- 
tion associated with said signaling node, said 
virtual link being operable to propagate mes- 
sages using Stream Control Transmission Pro- 
tocol (SCTP); 

verifying said virtual link's integrity by said sig- 
naling node; 

interworking, at said signaling node, between a 
Level 3 Message Transfer Part (MTP3) func- 
tionality and said SCTP protocol by a peer-to- 
peer protocol adaptation (PPA) structure pro- 
vided thereat, said PPA operating to convert 
SS7 signal bearer traffic into a stream of SCTP 
messages; and 

loading said virtual link with said stream of 
SCTP messages for propagation over said vir- 
tual link associated with said signaling link. 

38. The computer-accessible medium operable with a 
signaling node as set forth in claim 37, further 
including instructions for performing the steps of: 

determining if a predetermined quality condi- 
tion associated with said virtual link is 
degraded by a select amount; 

if so, suspending said stream of SCTP mes- 
sages on said virtual link and establishing an 
alternative link associated with said signaling 
node; and 

propagating said signal bearer traffic over said 
alternative link. 

39. The computer-accessible medium operable with a 
signaling node as set forth in claim 38, wherein said 
alternative link comprises an IP-based link. 

40. The computer-accessible medium operable with a 
signaling node as set forth in claim 38, wherein said 
alternative link comprises an SS7 link. 

41. The computer-accessible medium operable with a 
signaling node as set forth in claim 37, wherein said 
signaling node comprises an IP Signal Transfer 
Point (IPSTP). 



determining if a predetermined quality condi- 20 
tion associated with said virtual link between 
said two nodes is degraded by a select amount; 

if so, suspending said stream of SCTP mes- 
sages on said virtual link and establishing an 25 
alternative link between said two nodes; and 

30 
35 
40 
45 
50 
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42. The computer-accessible medium operable with a 
signaling node as set forth in claim 37, wherein said 
signaling node comprises an IP signaling endpoint 
(IPSEP). 

5 

43. The computer-accessible medium operable with a 
signaling node as set forth in claim 37, wherein said 
signaling node comprises an IP Service Control 
Point (IPSCP). 

10 

44. The computer-accessible medium operable with a 
signaling node as set forth in claim 37, wherein said 
signaling node comprises an IP media gateway 
controller (MGWC). 

15 

45. A link changeover method in an IP-based telecom- 
munications network for transporting SS7 signaling 
information, said network including a local node 
and a remote node, wherein each of said nodes 
includes an MTP3 structure, an M2PA structure, 20 
and an SCTP structure, comprising the steps of: 

establishing a link between said local and 
remote nodes by creating an association there- 
between; 25 



The link changeover method in an IP-based tele- 
communications network for transporting SS7 sign- 
aling information as set forth in claim 47, wherein 
said SS7 sequence number information comprises 
Backward Sequence Number information. 

The link changeover method in an IP-based tele- 
communications network for transporting SS7 sign- 
aling information as set forth in claim 47, wherein 
said select condition related to said association 
comprises a Quality of Service (QoS) condition. 

The link changeover method in an IP-based tele- 
communications network for transporting SS7 sign- 
aling information as set forth in claim 47, wherein 
said select condition related to said association 
comprises a link failure condition. 

The link changeover method in an IP-based tele- 
communications network for transporting SS7 sign- 
aling information as set forth in claim 47, wherein 
said select condition related to said association 
comprises a link reliability condition. 



detecting, by at least one of said local and 
remote nodes, that a select condition related to 
said association has occurred; 

30 

responsive to said detection step, exchanging 
message sequence number information 
between said local and remote nodes on an 
alternative link established therebetween; and 

35 

based on said message sequence number 
information, retransmitting messages over said 
alternative link, said messages starting at a 
predetermined sequence number. 

40 

46. The link changeover method in an IP-based tele- 
communications network for transporting SS7 sign- 
aling information as set forth in claim 45, wherein 
said message sequence number information com- 
prises SCTP sequence number information. 45 

47. The link changeover method in an IP-based tele- 
communications network for transporting SS7 sign- 
aling information as set forth in claim 45, wherein 
said message sequence number information com- 50 
prises SS7 sequence number information. 

48. The link changeover method in an IP-based tele- 
communications network for transporting SS7 sign- 
aling information as set forth in claim 47, wherein 55 
said SS7 sequence number information comprises 
Forward Sequence Number information. 
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